The rising popularity of mobile data plans and mobile broadband (MBB) in recent years, combined with the availability of cheap terminals (also widely referred to as “User Equipments” or “UEs”) with computer-like capabilities, such as smart phones, have increased the demands on telecommunications networks, particularly in terms of bandwidth capacity and quality of service QoS). Network operators of telecom networks providing mobile access and mobile equipment manufacturers are among those striving to find solutions to meet these increasing demands.
FIG. 1 is a simplified illustration of a telecommunications network comprising a mobile data network 10 which can connect a UE (e.g. a smart phone) to the Internet 30 via a proxy server 40, such that the UE 20 is able to download content and otherwise communicate with a web server 50 connected to the Internet 30.
To improve bandwidth availability in a telecommunications network such as the one shown in FIG. 1, the traffic crossing the network can be reduced by employing a communication protocol that supports compression. However, the decision to compress traffic is taken by the endpoints involved in the communication (for example, the UE 20 acting as a client and the web server 50 acting as a server in a client-server architecture, or the peers in a peer-to-peer architecture), with no room for the telecommunications data network mediating in the communication to impact on the decision.
It would be desirable for a telecom network that provides data communications between endpoints to be able to force compression at the Application Level (i.e. Layer 7, as understood in the sense of the OSI Reference Model), i.e. without having to compress the complete data stream/content (or, in other words, without tunnelling), under the following circumstances:                For payload traffic (contents) of protocols that have built-in support for compression; and        For clients and servers (or communicating peers, as the case may be) that, while supporting the option of compressing contents, have decided not to do so.        
Following these guidelines, protocols which are susceptible to forceful compression can be considered. The “Hypertext Transfer Protocol”, HTTP, is perhaps the best known case and will therefore be discussed in the following. Other application layer protocols (such as SOAP or XML-RPC) or web-based services (such as “Dropbox” or “Twitter”), which use HTTP as a basis, may also be considered as candidates in a scheme for forcing compression.
According to recent mobile traffic reports, HTTP-based traffic accounts for a substantial proportion of the data transmitted in mobile data networks. HTTP is the Application Level protocol used as the foundation for data communications in the World Wide Web. HTTP functions as a request-response protocol (using a client-server model), in accordance with which an HTTP client (typically a web browser) in the UE 20 (or in any other device that can connect to the mobile network using the UE 20) can contact an HTTP server (e.g. web server 50), and request some of the information which the HTTP server 50 stores, or alternatively sends the HTTP server 50 information for later processing. Requests for information from the web server 50 typically make use of an HTTP GET method, while uploads to the web server 50 may use the HTTP POST or GET methods, among others.
HTTP supports content compression, understood as the capability of communicating endpoints to send and receive compressed content to optimize the use of the underlying bandwidth resources and later present that information to upper layers in the Internet Protocol Suite in an uncompressed (and equal to the original) format. More specifically, protocols such as HTTP that support content compression do so by defining the control signalling required to allow an endpoint to indicate its willingness (or a preference) to receive compressed content of a specified compression format from another endpoint, as well as that required to allow an endpoint to provide an indication of whether content it sends to another endpoint is compressed and, if so, the compression format used.
Thus, the GE 20 functioning as an HTTP client that implements the current version of HTTP, namely HTTP/1.1, and is willing to accept compressed content in the form of IP datagrams containing compressed, encapsulated data, includes in the “Accept-Encoding” header in the Request sent to the web server 50 a list naming the compression schemas it supports. For example, the following “Accept-Encoding” header of an HTTP Request sent by an HTTP client shows that the client supports both “grip” and “deflate” schemas:                Accept-Encoding: grip, deflate        
Quality Values (so-called “qvalues”) can be used to express a preference. For example, in the following example, the client is expressing a preference for “grip” over “deflate”:                Accept-Encoding: grip; q=1.0, deflate; q=0.5, *; q=0        
If the web server 50 (or any HTTP entity acting as server and receiving the requests) supports any of the compression schemas proposed by the HTTP client 20, it may decide to compress the content in the reply according to that schema. The web server 50 is by no means obligated to perform any compression on the content, and would do so based on its internal configuration, internal capabilities, network or processing load and/or other factors.
If the web server 50 chooses to compress the content, it will include in a “Content-Encoding” header of its Response the schema used. For instance, the following example can be used to inform the HTTP client 20 that the content has been compressed using the “gzip” schema:                Content-Encoding: gzip        
HTTP content compression works well in reducing the bandwidth usage of HTTP when the client 20 supports compression and the server 50 chooses to send compressed content. In this respect, most modern web browsers, whether implemented in traditional personal computers or in modern mobile terminals, support HTTP content compression. Further details of HTTP content compression are provided in RFC 2616 “Hypertext Transfer Protocol HTTP/1.1”, June 1999).
In the example of FIG. 1, it is up to the HTTP client 20 to announce the compression schemas supported, and up to the HTTP server 50 to send the content either compressed or uncompressed. As noted above, the decision taken by the HTTP server 50 on whether or not to compress data it sends to the HTTP client 20 may depend on the server's configuration or other internal factors (e.g. processor load, since compressing data contents consumes processing resources) or perhaps external factors (e.g. local network segment). Thus, in general, an indication that compressed data content may be accepted by the HTTP client 20 (e.g. an “Accept-Encoding” header included in an HTTP Request sent by the client 20) does not necessarily force the HTTP server 50 to reply to the client 20 with compressed data contents, nor will it cause errors in the client 20 when the client receives uncompressed data contents in the HTTP Response. Instead, the HTTP server 50 can act according to local policies/status and/or by the format of its current data (for example, compression of data contents may not be allowed in the server 50, or the requested data contents may not be stored by the server 50 in a compressed format and its processing resources may be overloaded when it is replies to the client's Request, etc.).
Known content compression schemes (e.g. compression of HTTP data traffic) have the drawback of not being enforceable by telecommunications networks (for example, the mobile telecommunications network 10 shown in FIG. 1) in an unobtrusive way; for example, without the use of Application. Level intermediaries, usually known as “proxies” (such as web proxies, which are servers arranged to mediate in HTTP-based data traffic running between HTTP clients and HTTP servers), as will be discussed below.
For example, since the HTTP server 50 shown in FIG. 1 will generally be located beyond the network domain of the network operator owning the telecom network 10 that is used by the HTTP client 20 to access to the information (generally located in another domain of the Internet, the telecom network 10 will not have the means to influence decisions that can be taken by the HTTP server 50 and, more precisely, the decisions taken by the HTTP server 50 as to whether or not certain data contents to be delivered to the HTTP client 20 are to be compressed.
In the example of FIG. 1, the following situation may arise:                the HTTP client 20 supports content compression (e.g. HTTP content compression); and        the HTTP server 50 decides not to send the content compressed due to factors such as static configuration (correct or incorrect), a dynamic decision based on local knowledge, a local overload that prevents the server from devoting local resources to compress contents, etc.        
As a result, the load on the transmission resources of the nodes of the telecommunications network 10 used by the UE 20 acting as a client to access the data contents (e.g. Core Network nodes and Radio Access nodes of the telecom network 10 illustrated in FIG. 1), will increase as long as data packets of data flows that terminate and/or originate from user terminals (UEs) attached to a telecom network 10 are not compressed. Similar problems will arise in the telecom network components upstream of the mobile data network 10 (denoted by “Internet 30” in FIG. 1).
Web proxies, such as proxy server 40 shown in FIG. 1, can be introduced in the network to force compression. However, both standard proxy servers and transparent proxies are intrusive technologies in the sense that they either require changes to the client configuration (in the case of standard web proxies, where each client has to be configured to use a given proxy in order to forcefully compress traffic) or may disrupt the functionality of the HTTP protocol.
Web proxies, both standard and transparent, implement the diversion (interception) of the TCP connection establishment. This introduces problems since the mapping between the destination IP address and port and the target URL, as implemented by the client, may not match the one selected by the proxy, as web proxies should not access Transport Layer (i.e. Layer 4) information. Furthermore, the interception of the TCP connection establishment creates problems with connection-oriented authentication schemas, such as a NTLM, since the client browser believes it is talking to a server rather than a proxy. Well-known problems associated with the use of web proxies are set out in RFC 3143 (“Known HTTP Proxy/Caching Problems”, June 2001).
In summary, delivering uncompressed data contents over a telecommunications network can overload the transmission capacity of at least some of the network nodes (such as the Radio Access resources utilized by mobile terminals, the Packet Core resources and/or other components of the telecommunications network), thereby reducing network capacity. Different sections of the network will be affected differently but, in general, the transmission of uncompressed data will always have a negative impact on the network's transmission resources. Data compression can help to mitigate this problem. However, known schemes for forcing data compression, particularly those involving the use of proxies (e.g. web proxies and cache servers) have a number of drawbacks, as explained above.